Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/1145

Internet Message Format | 1994-08-27 | 6KB

From: [e-mail] (Mark Baker)
Date: 31 Jul 94  17:55:30
Message-Id: <UUCP.775721456@mettav>
Subject: Digest
To: [e-mail] ([e-mail])
Precedence: bulk

Warwick:
 >>> I know it might be hard to resist thinking of one's own machine as the
 >>> target for one's software and optimizing for that, but this really must
 >>> be avoided, especially by anyone want to follow a standard.
 >>
 >> But surely optimising for STs, TTs and Falcons, with or without Overscan,
 >>  Blowup etc, is better than optimising for graphics cards which a tiny
 >> minority have.
 >
 > Including Falcons in 256 colours and in TrueColour?  Use offscreen
 > bitmaps in those resolutions and you are talking major expense (640x480 - a
 > small offscreen bitmap - is almost a megabyte in Falcon HiColour).

I agree that in these resolutions you have a major memory cost for off-screen
bitmaps and they shouldn't be used (normally) for that reason, but in terms of
speed using an off-screen bitmap will be the fastest way on the Falcon, it is
only with graphics cards that it is faster to avoid them. And that is a tiny
minority of users.

 >> Balloon help... why not, it's a pity there isn't an
 >> efficient way to track menus (it can be done using timer events)
 >
 > Not true.  Rectangle events are provided to the application EVEN WHILE
 > THE MENUS ARE BEING USED.  Strange, but true.  (I can see it is going
 > to cause be problems, as the drop-down menus don't clip the rectangle
 > lists!)

I knew timer events worked when the menus are dropped, I think this is how
Calamus etc does it. But I don't like anything using short interval timer
events.

Rick:
 >> Windows in Dialogs is in my list because programs like Interface
 >> allow you to have modal dialogs in windows or just dialogs. The
 >> advantage of not using dialogs is speed - when you are updating
 >> 20 items and have to bring up a dialog for each one, the small
 >> wait involved while the window draws can get annoying.
 >
 > That must depend on code speed. I can't see any noticeable difference in
 > opening a windowed dialog vs. a regular dialog under Geneva (that's on an
 > 8mhz 68000). I would guess that if someone else's code is slow, that can
 > be improved.

Opening windows is fairly slow under MultiTOS but not unreasonably so. What is
slow about windowed dialogues is that the other windows are redrawn when the
dialogue is closed. This is the same as normal dialogues, unless you have LTMF
installed which will blit to restore the screen and makes it much faster. I use
windowed dialogues despite the speed penalty but if I had a slower machine I
probably wouldn't.

 >> program's own preferences file, and I take it that APP_DEFS conforming
 >> programs will not use their own preference files: Am I right or wrong?
 >
 > dialog_positions for NeoDesk). I doubt you would want an APP_DEFS file
 > overwhelmed by all that application specific stuff.

I agree. Programs should not put their own specific stuff into it, or it will
get like the windows win.ini file.

Evan:
 > Click-Move-Click?   Do you really use that?
 > All I can say is .. YUCK!   Implementing that would not only be
 > a pain, but wouldn't be possible without really screwing things up.
 > At least, not without providing your own sizer and mover.

Which he (Dan Hollis) did. As a result his library looks and feels like no
other GEM program.

 > The left handed thing was good though.  I'm glad you brought it up, even
 > though I'm right handed like everyone else.

The window gadgets and menu items - and old applications - will still be
right-handed if it is changed on an application basis. You really need this to
be a system-wide option, perhaps implemented as a TSR.

Tim:
 >>> I am one of many people who have complained about Atari Works wiping
 >>> out their documents when their little finger slips and hits Ctrl and A at
 >>> the same time.
 > Ok... look at it this way.  Ctrl-A is dangerous, but some people want

It shouldn't be dangerous. If a program lets you delete the whole document
without confirmation it is flawed. If it lets you delete without being able to
undo it is flawed. The same applies to replacing with typing, which I assume is
how you lost stuff.

 > I don't want app_defs.sys turning into another win.ini.  When you install
 > a Windoze program, it adds all this CRAP to your system files like
 > win.ini, etc., and then when you want to remove the app, you still have
 > this crap in your win.ini file.

That is why I don't want to see application specific stuff in there.

BTW, I gave a rather bad example of why application classes are useful in a
past message. A better example is open. In a desktop, file management program,
or similar return is easiest, in a document- based program you would want ^O or
whatever.

 > Also, my library doesn't directly support MODAL dialogs.  If you want to
 > make something modal, you have to set the disabled flags of any other
 > dialog you don't want topped.  Additionally, you would have to disable
 > the menubar yourself... I could add a little routine to disable all menu
 > titles if necessary.

Disable all menu titles except the desk menu, so the user can still open an
accessory or switch to a different program.

 > How is a menu structured?  It seems kinda odd the way the objects are
 > arranged in it... boxes, iboxes, etc.  What's a sure way to just go
 > through JUST the titles one at a time?  How do I get the first title?
 > Require the programmer to pass the object number of the desk title?  That
 > would make it easiest.

It is a very wierd structure. But the titles are a separate type of object, the
ob_type field will be G_TITLE (32). So you could just search for these.